Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@kits/clinical-note-red-flag-scanner/agent.md`:
- Around line 15-19: Revise the standards-alignment section and guardrail claims
in kits/clinical-note-red-flag-scanner/agent.md at lines 15-19 to state only
that the template may support documentation-review workflows, and explicitly
disclaim regulatory compliance certification. Apply the same narrowed wording
and disclaimer to the user-facing compliance statement in
kits/clinical-note-red-flag-scanner/README.md at lines 12-14.
- Around line 29-33: Update the input-note guidance in the agent documentation
to remove the “any length” claim. Define and enforce a maximum supported note
size or implement chunking before scanning, document the actual limit and
behavior for oversized notes, and keep the required clinicalNote input contract
unchanged.

In `@kits/clinical-note-red-flag-scanner/flows/clinical-note-red-flag-scanner.ts`:
- Around line 159-163: Update the finalText mapping in the Variables node to
reference only LLMNode_453.output.generatedResponse, removing the trailing
literal “{” so the complete model response remains valid JSON.
- Around line 110-115: Update the API Request trigger configuration for nodeName
"API Request" so advance_schema requires clinicalNote to be a non-empty,
non-whitespace string. If the schema cannot express trimming, add an explicit
guard immediately before the LLM node that rejects empty or whitespace-only
clinicalNote values before scanning.

In `@kits/clinical-note-red-flag-scanner/lamatic.config.ts`:
- Around line 9-12: Add the deployment environment key to the mandatory step
configuration identified by id "clinical-note-red-flag-scanner", using the step
ID expected by runtime flow resolution so it can read the deployed flow ID from
process.env. Preserve the existing id and type values.

In
`@kits/clinical-note-red-flag-scanner/prompts/clinical-note-red-flag-scanner_llmnode-453_system_0.md`:
- Line 13: Update the REGULATORY guidance in the clinical-note red-flag scanner
prompt to require jurisdiction and care-setting context before emitting
regulatory findings. If those inputs are unavailable, restrict findings to
requirements explicitly identified by the caller or documented in the note; do
not make jurisdiction-specific claims from clinicalNote alone.
- Line 5: Update the DRUG_INTERACTION category definition in the system prompt
to avoid claiming definitive or exhaustive detection without an authoritative
interaction source; either specify a versioned, clinically verified interaction
database/tool, or restrict findings to interactions explicitly documented in the
note and label screening as non-exhaustive.
- Around line 23-27: Update the recommendation field instructions and the
prohibition near the medical-advice guidance to require documentation-only
remediation actions. Explicitly prohibit treatment choices, dosing regimens,
diagnoses, and triage or emergency-care advice, and revise the README example to
remove nitroglycerin and emergency-care instructions.
- Around line 15-30: Update the JSON response contract in the system prompt to
explicitly require that flagCount equals flags.length, flag IDs are unique and
sequential starting at FLAG-001, and category and severity values use only the
defined valid codes. Require responses to satisfy these invariants in addition
to the existing structure.
- Around line 37-42: Update the evidence guidance near the flag-generation rules
so `detail` and `location` use redacted or paraphrased evidence rather than
reproducing exact patient text. Explicitly prohibit names, MRNs, DOBs, contact
information, and other identifiers while preserving enough non-identifying
context to support each flag.

In
`@kits/clinical-note-red-flag-scanner/prompts/clinical-note-red-flag-scanner_llmnode-453_user_1.md`:
- Around line 1-2: Update the clinicalNote interpolation in the clinical-note
scanner prompt to prevent raw PHI from being sent to Gemini. Require a
pre-redacted or de-identified note, or enforce a documented compliant
zero-retention provider configuration before forwarding the content; do not rely
on prompt-level confidentiality instructions.
- Around line 1-2: Update the clinical-note prompt content around
triggerNode_1.output.clinicalNote to clearly delimit the note as untrusted data
and explicitly instruct the model to ignore any commands or instructions
contained within it, while preserving the required JSON, confidentiality, and
safety behavior.

In `@kits/clinical-note-red-flag-scanner/README.md`:
- Around line 1-8: Move the “# Clinical Note Red-Flag Scanner” H1 above the
deploy badge HTML so it is the README’s first content and satisfies MD041. Keep
the existing badge markup unchanged below the heading.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In
`@kits/clinical-note-red-flag-scanner/prompts/clinical-note-red-flag-scanner_llmnode-453_system_0.md`:
- Line 13: Update the REGULATORY guidance in the system prompt to require
jurisdiction and care setting before making jurisdiction-specific findings. When
those inputs are unavailable, limit findings to requirements explicitly
identified by the caller or clinical note and label them non-jurisdictional.

In
`@kits/clinical-note-red-flag-scanner/prompts/clinical-note-red-flag-scanner_llmnode-453_user_1.md`:
- Line 4: Update the prompt input around clinicalNote so raw clinical notes
cannot be forwarded directly to Gemini without a data-control boundary. Require
and validate pre-redacted/de-identified content, or verify a compliant
zero-retention provider configuration before executing the node; otherwise block
execution rather than interpolating the complete note.

---

Outside diff comments:
In `@kits/clinical-note-red-flag-scanner/README.md`:
- Around line 67-69: Replace the clinicalNote example in the README with clearly
synthetic, non-identifying content that does not resemble real patient data or
include names, demographics, dates of birth, MRNs, or other identifiers. Update
the related example at the referenced reproduction section as well, removing any
demonstration of identifier reproduction while preserving the red-flag scanner
usage context.
- Around line 105-116: Update the example output entries FLAG-003 and FLAG-004
in the README so their recommendation text only instructs users to document
missing clinical fields or plan details. Remove medication dosing guidance and
emergency-care or return-to-ED instructions while preserving the existing
finding context.
- Around line 73-80: Update the “Example Output” section to match the runtime
contract: show the outer result field and represent its value as the serialized
JSON string returned by the flow. Keep the documented summary and flagCount
payload consistent with the implementation and related flow/agent documentation.

---

Duplicate comments:
In `@kits/clinical-note-red-flag-scanner/flows/clinical-note-red-flag-scanner.ts`:
- Line 114: Enforce the documented 10,000-token maximum in the clinical note
trigger contract around the advance_schema definition by adding bounded
validation or chunking before the single LLM request. In
kits/clinical-note-red-flag-scanner/flows/clinical-note-red-flag-scanner.ts:114,
reject or appropriately process oversized clinicalNote values; in
kits/clinical-note-red-flag-scanner/agent.md:33, document the enforced limit and
the behavior for oversized input.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@kits/clinical-note-red-flag-scanner/README.md`:
- Line 79: Update the example JSON result so its summary matches the emitted
flags: either add a corresponding CONSENT entry to the flags array, or remove
the informed-consent claim from the summary while preserving the existing
five-flag output.

---

Outside diff comments:
In `@kits/clinical-note-red-flag-scanner/flows/clinical-note-red-flag-scanner.ts`:
- Around line 161-181: Validate and normalize the LLM report before the
responseNode named “API Response” returns it: parse the generatedResponse from
LLMNode_453, enforce the documented schema and flagCount/ID/category invariants,
and reject malformed or markdown-wrapped output. Update the variablesNode_197
mapping so outputMapping uses only the validated report, preserving the existing
finalText/result contract for valid responses.

In `@kits/clinical-note-red-flag-scanner/README.md`:
- Line 20: Update the DRUG_INTERACTION description in the README to describe
only medication interactions explicitly documented or suggested by the clinical
note, and clearly state that the scanner does not provide definitive or
exhaustive interaction checking.
- Around line 75-80: Update the README prose describing the flow’s result field
to state that result is a JSON string containing the serialized report, not a
JSON object. Keep the existing example and JSON structure unchanged.

---

Duplicate comments:
In `@kits/clinical-note-red-flag-scanner/flows/clinical-note-red-flag-scanner.ts`:
- Line 114: Add jurisdiction and care-setting inputs to the flow’s
advance_schema and make them available to the regulatory-analysis prompt before
emitting REGULATORY findings. Alternatively, constrain REGULATORY results to
requirements explicitly identified by the clinical note or caller and label
those findings non-jurisdictional; preserve the existing clinicalNote
validation.
- Line 114: Update the clinical note execution flow around the advance_schema
configuration to enforce the PHI boundary before any Gemini request: require a
completed pre-redaction/attestation gate or verify a compliant provider
configuration, and reject or stop processing when neither condition is
satisfied. Do not rely on the schema’s length or whitespace validation as
de-identification.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@kits/clinical-note-red-flag-scanner/README.md`:
- Line 79: Update the example JSON in the README so the summary’s risk claims
match the listed flag categories: either remove “regulatory” from the summary or
add a corresponding REGULATORY flag, while preserving the existing category
invariant and JSON structure.

---

Outside diff comments:
In `@kits/clinical-note-red-flag-scanner/agent.md`:
- Around line 92-93: Update the Data Privacy guidance in
kits/clinical-note-red-flag-scanner/agent.md at lines 92-93 to require
independently verified provider authorization and contractual/security controls
for PHI processing; do not present zero retention as sufficient. Apply the same
prerequisite wording to the setup instructions in
kits/clinical-note-red-flag-scanner/README.md at line 61.

In
`@kits/clinical-note-red-flag-scanner/prompts/clinical-note-red-flag-scanner_llmnode-453_system_0.md`:
- Line 37: Update the evidence guidance in the clinical note red-flag scanner
prompt to remove the requirement to cite exact text. Require only redacted or
paraphrased evidence in the detail and location fields, explicitly prohibiting
verbatim patient text and identifiers such as names, MRNs, and DOBs.
- Line 13: Constrain the REGULATORY guidance in
kits/clinical-note-red-flag-scanner/prompts/clinical-note-red-flag-scanner_llmnode-453_system_0.md
at line 13 to note-explicit, non-jurisdictional observations, or add the
required jurisdiction and care-setting inputs to the flow. Update
kits/clinical-note-red-flag-scanner/agent.md at line 105 to remove the
unsupported claim that callers can supply context, and update
kits/clinical-note-red-flag-scanner/README.md at line 86 to document the same
enforceable limitation.

In `@kits/clinical-note-red-flag-scanner/README.md`:
- Around line 31-33: Update the input schema documentation near “Flow
Components” to reflect the enforced clinicalNote constraints: minimum 10
characters, maximum 45,000 characters, and at least one non-whitespace
character. Alternatively, clearly label the existing shape as illustrative
rather than complete.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@kits/clinical-note-red-flag-scanner/agent.md`:
- Line 92: The limitations guidance in
kits/clinical-note-red-flag-scanner/agent.md lines 92-92 must require
independently verified provider PHI authorization together with contractual and
security controls, without presenting zero retention as an alternative. Apply
the same authorization requirement to the user-facing setup guidance in
kits/clinical-note-red-flag-scanner/README.md lines 61-61.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@kits/clinical-note-red-flag-scanner/agent.md`:
- Line 93: Update the Data Handling statement in the agent instructions to
describe only PII protections enforced by the template, removing any guarantee
about Gemini or other provider logging, storage, or repetition; explicitly
require callers to verify the provider’s retention and PHI-processing controls.

---

Outside diff comments:
In
`@kits/clinical-note-red-flag-scanner/prompts/clinical-note-red-flag-scanner_llmnode-453_system_0.md`:
- Around line 31-35: Update the Severity Definitions in
kits/clinical-note-red-flag-scanner/prompts/clinical-note-red-flag-scanner_llmnode-453_system_0.md:31-35
to remove jurisdictional regulatory and contraindication-based claims, using
note-explicit documentation-risk examples instead. Also update
kits/clinical-note-red-flag-scanner/README.md:28 to replace “specific regulatory
requirements” with a general, non-jurisdictional description of REGULATORY
documentation expectations.